我們常會使用業務性質來界定領域範圍(Bounded Context),例如,採購、銷售、庫存、運輸、會計...等,一般而言,這並沒有問題,但是,回到中台架構的理念,我們希望透過共享架構的建立,達到復用(Reuse)的能力,因此,以業務性質界定領域範圍後,應該進一步進行水平整合,將共有的功能獨立出來,才能建構共享、復用的平台。
企業資源有限,開發團隊可能無法在短時間內滿足所有業務需求,因此,必須把領域範圍區分為核心域(Core domain)、支撐域(Supporting domain)及通用域(Generic domain),然後把焦點集中在核心域,創造競爭優勢,支撐域可以外購或外包,配合公司業務的快速發展,例如,餐飲業可以把外送業務直接委託FoodPanda、Uber...等外送平台,至於通用域就必須慎重考慮,例如,權限控管機制關係到單一登入(Single Sign-On, SSO)的重大決策,又客戶管理領域牽涉到各部門,如何方便共享並兼顧隱私權的維護,不管是外購或自建,都必須考慮到戰略資訊系統的長遠規劃。以產物保險系統為例,可以作以下的切割:
圖一. 產物保險系統子領域的切割
DDD 使用 Context Map 界定與外部系統的關聯,DDD發明人Eric Evans將關聯按控制(Control)與通訊(Communication)的依存度分為九種,如下圖:
圖二. 系統關聯的類型,圖片來源:Domain-Driven Design: Strategic Patterns
九種關聯模式說明如下:
區分這些模式有點政治化,可能因一方比較強勢,就會決定使兩個系統的關聯模式要採用那一種,不管如何,一但決定了,後續架構及設計就需因應發展。
Eric Evans特別提到舊系統的汰換,不要想一步淘汰舊系統,可以利用防腐層模式接通舊系統,再逐步利用新技術,將舊系統的功能一塊一塊替換掉,這是一個好主意,可以降低風險。
為了程式容易擴充與維護,通常我們會對系統架構進行分層,不論是 Client/Server、N-Tier、MVC/MVVM...等,都是將程式的使用者介面(UI)、業務邏輯及資料庫存取分離,避免單一檔案過大,且混在一起很難修改,DDD也不例外,將架構分為四層,如下圖:
圖三. DDD分層架構,圖片來源:Implementing Domain-Driven Design
DDD將中間層分為應用層(Application Layer)及領域層(Domain Layer),領域層包裹領域模型,並將相關業務邏輯涵蓋在內,應用層只是薄薄一層,組合相關領域模型,負責安全認證、發送通知、...等事務。另外,DDD強調設計模式(Design Pattern),例如依賴注入(Dependency Injection, DI)可反轉圖三架構,以宣告式方式產生物件,或是Repository Pattern結合工廠模式(Factory Pattern),可統合一般物件的新增、更新、刪除、查詢等共通功能,避免每個類別重複撰寫類似的程式碼。
完整的架構可參考下圖:
圖四. 詳細的DDD分層架構,圖片來源:一文解析DDD中台和微服务设计
由上介紹,戰略設計(Strategic Design)相當於架構規劃,良好的規劃是專案成功的第一步,規劃的初衷永遠不要忘記:
不要以職場政治為唯一考量。